Making Components Contract Aware

38 Computer Making Components Contract Aware C omponents have long promised to neatly encapsulate data and programs into a box that operates predictably without requiring that users know the specifics of how it does so. Many advocates have predicted that components will bring about the bright future of large-scale software reuse, spawning a market for components usable with such mainstream software buses as the Common Object Request Broker Architecture (CORBA) and Distributed Component Object Model (DCOM). In the Windows world, at least, this prediction is becoming a reality. Yet recent reports 1,2 indicate mixed results when using and reusing components in mission-critical settings. Such results raise disturbing questions. How can you trust a component? What if the component behaves unexpectedly, either because it is faulty or simply because you misused it? Mission-critical systems cannot be rebooted as easily as a desktop computer. We thus need a way of determining beforehand whether we can use a given component within a certain context. Ideally, this information would take the form of a specification that tells us what the component does without entering into the details of how. Further, the specification should provide parameters against which the component can be verified and validated, thus providing a kind of contract between the component and its users. In real life, contracts exist at different levels, from Jean-Jacques Rousseau's social contract to negotiable contracts, from various forms of license agreements to cash-and-carry. Likewise, we have identified four classes of contracts in the software component world: basic or syntactic, behavioral, synchronization, and quantitative. Responsibility for contract management must be shared by both client and service provider. In those cases where the contracts are self-explanatory, assigning responsibility is easy. But some contracts rely on external constraints that too often remain implicit. In particular, quantitative contracts such as quality of service refer to features " outside the box, " which reside in the system layer on which client and provider run. In this article we define a general model of software contracts and show how existing mechanisms could be used to turn traditional components into contract-aware ones. When we apply contracts to components, we find that such contracts can be divided into four levels of increasingly negotiable properties, as Figure 1 shows. The first level, basic, or syntactic, contracts, is required simply to make the system work. The second level, behavioral contracts , improves the level of confidence in …